home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / internet-drafts / draft-ietf-pem-mime-01.txt < prev    next >
Text File  |  1993-03-21  |  18KB  |  584 lines
  1.           Network Working Group                            Steve Crocker
  2.           Internet Draft                                       Ned Freed
  3.                                                            Marshall Rose
  4.  
  5.                                MIME-PEM Interaction
  6.  
  7.                              Mon Jan 11 02:20:00 1993
  8.  
  9.  
  10.  
  11.  
  12.           1.  Status of this Memo
  13.  
  14.           This document is an Internet Draft. Internet Drafts are
  15.           working documents of the Internet Engineering Task Force
  16.           (IETF), its Areas, and its Working Groups.  Note that other
  17.           groups may also distribute working documents as Internet
  18.           Drafts.
  19.  
  20.           Internet Drafts are valid for a maximum of six months and may
  21.           be updated, replaced, or obsoleted by other documents at any
  22.           time. It is inappropriate to use Internet Drafts as reference
  23.           material or to cite them other than as a "work in progress".
  24.  
  25.  
  26.           2.  Abstract
  27.  
  28.           This memo defines a framework for interaction between MIME and
  29.           PEM services.
  30.  
  31.  
  32.           3.  Introduction
  33.  
  34.           In the Internet community, an electronic mail message has two
  35.           parts: the headers and the body. The headers form a collection
  36.           of field/value pairs structured according to RFC 822 [1],
  37.           whilst the body, if structured, is defined according to
  38.           Multipurpose Internet Mail Extensions (MIME) [2].
  39.  
  40.           Privacy Enhanced Mail (PEM) [3-6] allows encryption and
  41.           authentication services to be applied to an electronic mail
  42.           message.
  43.  
  44.           This memo defines a framework whereby the services provided by
  45.           MIME and PEM are used in a complementary fashion.
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.           draft                MIME-PEM Interaction               Jan 93
  58.  
  59.  
  60.           In order to provide for MIME-PEM interaction, two content
  61.           types, "multipart/pem" and "application/pem", are defined.
  62.           Then, the relationship between MIME and PEM is described in
  63.           terms of two functions: message composition and message
  64.           delivery.
  65.  
  66.  
  67.           4.  Definiton of new Content Types
  68.  
  69.  
  70.           4.1.  Definition of the multipart/pem Content Type
  71.  
  72.           (1)  MIME type name: multipart
  73.  
  74.           (2)  MIME subtype name: pem
  75.  
  76.           (3)  Required parameters: boundary, privacy
  77.  
  78.           (4)  Optional parameters: none
  79.  
  80.           (5)  Encoding considerations: always 7bit
  81.  
  82.           (6)  Security Considerations: see [3]
  83.  
  84.  
  85.           This subtype of multipart always contains two body parts: the
  86.           first is an arbitrary content and the second is an
  87.           application/pem content which describes the privacy-
  88.           enhancements which resulted in the first body part.
  89.  
  90.           The value of the first body part corresponds to <pemtext> as
  91.           defined in [3].  Note that if <pemtext> is represented using
  92.           the base64 encoding, then a Content-Transfer-Encoding: header
  93.           is present which indicates use of the base64 content encoding.
  94.           This Content-Transfer-Encoding must be used for encrypted
  95.           <pemtext>. Any Content-Transfer-Encoding may be used when
  96.           <pemtext> is not encrypted, although some form of encoding is
  97.           recommended to protect the contents from damage that may
  98.           subsequently cause message integrity check (MIC) failure.
  99.  
  100.  
  101.           The syntax and semantics of the boundary parameter is defined
  102.           in [2].
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.           Expires May 16, 1993                                  [Page 2]
  111.  
  112.  
  113.  
  114.  
  115.  
  116.           draft                MIME-PEM Interaction               Jan 93
  117.  
  118.  
  119.           The syntax of the privacy parameter, using the ABNF notation
  120.           of [1], is:
  121.  
  122.                privacy-value   ::= "ENCRYPTED"
  123.                                  / "MIC-ONLY"
  124.  
  125.           with each value conveying the intent as specified in [3]. Note
  126.           that MIC-CLEAR is not provided directly; it is subsumed by the
  127.           combination of MIC-ONLY and the MIME Content-Transfer-Encoding
  128.           mechanism that is available to any body part.
  129.  
  130.  
  131.           4.2.  Definition of the application/pem Content Type
  132.  
  133.           (1)  MIME type name: application
  134.  
  135.           (2)  MIME subtype name: pem
  136.  
  137.           (3)  Required parameters: none
  138.  
  139.           (4)  Optional parameters: none
  140.  
  141.           (5)  Encoding considerations: always 7bit
  142.  
  143.           (6)  Security Considerations: see [3]
  144.  
  145.  
  146.           The syntax of this content type corresponds to the <pemhdr>
  147.           production defined in [3].
  148.  
  149.  
  150.           5.  Message Composition
  151.  
  152.           When a user composes a message, it is the responsibility of
  153.           the user agent to use Content-Type: headers. This allows the
  154.           receiving user agent to unambiguously interpret the body and
  155.           process it accordingly.
  156.  
  157.           Each block of content headers associated with either an RFC822
  158.           <message> or with a MIME <body-part> represents a logical
  159.           place where privacy enhancement can be requested. A privacy
  160.           enhancement request associated with particular <message> or
  161.           <body-part> content is taken to apply to the entire content;
  162.           it is not possible to privacy-enhance only a piece of a body
  163.           part.
  164.  
  165.  
  166.  
  167.  
  168.  
  169.           Expires May 16, 1993                                  [Page 3]
  170.  
  171.  
  172.  
  173.  
  174.  
  175.           draft                MIME-PEM Interaction               Jan 93
  176.  
  177.  
  178.           Since the semantics of privacy enhancment requests closely
  179.           parallel those of an additional Content- header, the use of an
  180.           additional Content- header for this purpose is a reasonable,
  181.           but not required, approach. If a Content- header is used for
  182.           this purpose, this memo suggests that a new header field,
  183.           "Content-Privacy", be used for this purpose. The syntax of
  184.           this header field corresponds to the <privacy-value>
  185.           production defined above.
  186.  
  187.                                        NOTE
  188.                This Content-Privacy header is only a suggested mechanism
  189.                -- the interface between the message composer and pre-
  190.                submission processing is entirely a local matter, and in
  191.                general any mechanism with comparable semantics can be
  192.                used.  More to the point, the interface between the
  193.                message composer and pre-submission processing MUST be
  194.                trustworthy, since the message composer relies on pre-
  195.                submission processing to either perform the requested
  196.                privacy enhancement operation or return an error.
  197.                Regardless of the mechanism chosen, great care should be
  198.                taken to safeguard against the release of information
  199.                that has not received the requested sort of privacy
  200.                enhancement.
  201.  
  202.  
  203.           5.1.  Pre-Submission Algorithm
  204.  
  205.           Prior to submission, the user agent applies this algorithm:
  206.  
  207.           (1)  If the content has not been selected for privacy
  208.                enhancement, then the user agent sees if the content is
  209.                either multipart or message. If so, it then recursively
  210.                applies this algorithm to the encapsulated body parts; if
  211.                not, it terminates processing for this content.
  212.  
  213.           (2)  If the content has been selected for privacy enhancement,
  214.                the content is transformed from local form to its MIME
  215.                binary canonical form. Note that if Content-Transfer-
  216.                Encoding: headers are present the content encoding is
  217.                reversed as a part of this process, leaving only 7BIT,
  218.                8BIT, and BINARY as possible encodings for all body
  219.                parts.
  220.  
  221.           (3)  Otherwise, the selected privacy-enhancement is performed,
  222.                constructing a new content. The Content- headers, other
  223.  
  224.  
  225.  
  226.  
  227.  
  228.           Expires May 16, 1993                                  [Page 4]
  229.  
  230.  
  231.  
  232.  
  233.  
  234.           draft                MIME-PEM Interaction               Jan 93
  235.  
  236.  
  237.                than Content-Transfer-Encoding: and Content-Privacy: (if
  238.                this header is used), are taken from the original
  239.                content, if any.
  240.  
  241.           (4)  If the selected privacy-enhancement is ENCRYPTED, then
  242.                the base64 Content-Transfer-Encoding is applied and a
  243.                Content-Transfer-Encoding: header is added to the new
  244.                content. If the selected privacy-enhancement is MIC-ONLY,
  245.                a Content-Transfer-Encoding other than 7bit must be used
  246.                only if the content data requires it. However, at a
  247.                mimimum the use of the quoted-printable Content-
  248.                Transfer-Encoding is strongly recommended to insure that
  249.                the message is not damaged in transit, causing the MIC to
  250.                fail.
  251.  
  252.           (5)  Finally, a multipart/pem content is constructed, which
  253.                contains the new content and a corresponding
  254.                application/pem content. The multipart/pem content
  255.                replaces the original content.
  256.  
  257.  
  258.           6.  Message Delivery
  259.  
  260.           When a user receives a message containing an multipart/pem
  261.           content, the user agent may transform the content back into
  262.           its original content type. This operation, the post-delivery
  263.           algorithm, is performed by reversing the steps performed
  264.           during the pre-submission algorithm.
  265.  
  266.           When the original content is reconstituted into its MIME
  267.           binary canonical form, it may use octet values outside of the
  268.           US-ASCII repertoire and may contain body parts without line
  269.           breaks. If the user agent replaces the multipart/pem content
  270.           with the original content, then it must select appropriate
  271.           Content-Transfer-Encodings for each body part and add
  272.           corresponding Content-Transfer-Encoding: headers.
  273.  
  274.           Upon successful completion of the post-delivery algorithm for
  275.           each content, the type of privacy enhancement that was in
  276.           effect for that content must be communicated to the user. Once
  277.           again, the semantics of these indicators closely parallel
  278.           those of a Content- header. If the header approach is chosen,
  279.           it is suggested that a new header field, "Content-Annotation",
  280.           be used for this purpose. The syntax of this suggested header
  281.           field, using the ABNF notation of [1], is:
  282.  
  283.  
  284.  
  285.  
  286.  
  287.           Expires May 16, 1993                                  [Page 5]
  288.  
  289.  
  290.  
  291.  
  292.  
  293.           draft                MIME-PEM Interaction               Jan 93
  294.  
  295.  
  296.                content-annotation ::= "Content-Annotation" ":"
  297.                                                      annotation-value
  298.  
  299.                annotation-value   ::= <privacy-value> ";" <date-time>
  300.  
  301.           with <privacy-value> corresponding to the privacy-enhancement
  302.           that was in effect during submission, and <date-time>, defined
  303.           in [1], indicates the date and time when the privacy-
  304.           enhancement was verified by the receiving user agent.
  305.  
  306.                                        NOTE
  307.                As with requests for privacy enhancement to the pre-
  308.                submission algorithm, the path between post-delivery and
  309.                actual display of the message must be a trusted one, lest
  310.                a message be presented that purports to have had a
  311.                <privacy-value> it did not in fact possess.
  312.  
  313.  
  314.           7.  An Example
  315.  
  316.           For example, suppose the following message was being readied
  317.           for submission:
  318.  
  319.                Date:    Thu, 12 Nov 1992 21:43:40 -0800
  320.                From:    scrocker@tis.com
  321.                To:      ned@innosoft.com
  322.                Subject: example #1
  323.                MIME-Version:    1.0
  324.                Content-Type:    text/plain; charset=us-ascii
  325.                Content-Privacy: mic-only
  326.  
  327.                Hi Ned.  See how much nicer this works!
  328.  
  329.           After applying pre-submission algorithm, the message submitted
  330.           for delivery would appear as:
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338.  
  339.  
  340.  
  341.  
  342.  
  343.  
  344.  
  345.  
  346.           Expires May 16, 1993                                  [Page 6]
  347.  
  348.  
  349.  
  350.  
  351.  
  352.           draft                MIME-PEM Interaction               Jan 93
  353.  
  354.  
  355.                Date:    Thu, 12 Nov 1992 21:43:40 -0800
  356.                From:    scrocker@tis.com
  357.                To:      ned@innosoft.com
  358.                Subject: example #1
  359.                MIME-Version: 1.0
  360.                Content-Type: multipart/pem; boundary="next-part";
  361.                                             privacy=mic-only
  362.  
  363.  
  364.                --next-part
  365.                Content-Type: text/plain; charset=us-ascii
  366.  
  367.                Hi Ned.  See how much nicer this works!
  368.  
  369.                --next-part
  370.                Content-Type: application/pem
  371.  
  372.                Proc-Type: 4,MIC-ONLY
  373.                Content-Domain: RFC822
  374.                Originator-ID-Asymmetric: ...
  375.                MIC-Info: RSA-MD5,RSA, ...
  376.  
  377.                --next-part--
  378.  
  379.  
  380.           After applying the post-delivery algorithm, the resulting
  381.           message would appear as:
  382.  
  383.                Date:    Thu, 12 Nov 1992 21:43:40 -0800
  384.                From:    scrocker@tis.com
  385.                To:      ned@innosoft.com
  386.                Subject: example #1
  387.                MIME-Version:      1.0
  388.                Content-Type:      text/plain; charset=us-ascii
  389.                Content-Annotation: mic-only;
  390.                                    Thu, 12 Nov 1992 22:13:40 -0800
  391.                                    (integrity verified)
  392.  
  393.                Hi Ned.  See how much nicer this works!
  394.  
  395.           Of course, as the message being submitted was only plain US-
  396.           ASCII text, the Content-Type: header could be ommitted. In
  397.           that case, after applying the pre-submission algorithm, the
  398.           message submitted for delivery would appear as:
  399.  
  400.  
  401.  
  402.  
  403.  
  404.  
  405.           Expires May 16, 1993                                  [Page 7]
  406.  
  407.  
  408.  
  409.  
  410.  
  411.           draft                MIME-PEM Interaction               Jan 93
  412.  
  413.  
  414.                Date:    Thu, 12 Nov 1992 21:43:40 -0800
  415.                From:    scrocker@tis.com
  416.                To:      ned@innosoft.com
  417.                Subject: example #1
  418.                MIME-Version: 1.0
  419.                Content-Type: multipart/pem; boundary="next-part";
  420.                                             privacy=mic-only
  421.  
  422.  
  423.                --next-part
  424.  
  425.                Hi Ned.  See how much nicer this works!
  426.  
  427.                --next-part
  428.                Content-Type: application/pem
  429.  
  430.                Proc-Type: 4,MIC-ONLY
  431.                Content-Domain: RFC822
  432.                Originator-ID-Asymmetric: ...
  433.                MIC-Info: RSA-MD5,RSA, ...
  434.  
  435.                --next-part--
  436.  
  437.  
  438.           8.  Observations
  439.  
  440.           The use of the pre-submission and post-delivery algorithms
  441.           exhibit several properties:
  442.  
  443.           (1)  It allows privacy-enhancement of an arbitrary content,
  444.                not just an entire RFC 822 message.
  445.  
  446.           (2)  For a multipart or message content, it allows the user to
  447.                decide whether the structure of the content should
  448.                receive privacy-enhancement.
  449.  
  450.           (3)  It allows a message to contain several privacy enhanced
  451.                contents, thereby removing the requirement for PEM
  452.                software to be able to generate or interpret a single
  453.                content which intermixes both unenhanced and enhanced
  454.                components.
  455.  
  456.           (4)  It minimizes confusion when viewing a MIC-ONLY content
  457.                without a PEM-capable user agent.
  458.  
  459.  
  460.  
  461.  
  462.  
  463.  
  464.           Expires May 16, 1993                                  [Page 8]
  465.  
  466.  
  467.  
  468.  
  469.  
  470.           draft                MIME-PEM Interaction               Jan 93
  471.  
  472.  
  473.           (5)  It minimizes confusing when viewing a MIC-ONLY content
  474.                with a MIME-capable user agent that is not PEM-capable.
  475.  
  476.  
  477.           9.  Acknowledgements
  478.  
  479.           David H. Crocker suggested the use of a multipart structure
  480.           for MIME-PEM interaction.
  481.  
  482.  
  483.           10.  References
  484.  
  485.           [1]  D.H. Crocker.  Standard for the Format of ARPA Internet
  486.                Text Messages.  Request for Comments 822, (August, 1982).
  487.  
  488.           [2]  N. Borenstein, N. Freed, Multipurpose Internet Mail
  489.                Extensions.  Request for Comments 1341, (June, 1992).
  490.  
  491.           [3]  J. Linn, Privacy Enhancement for Internet Electronic
  492.                Mail -- Part I: Message Encryption and Authentication
  493.                Procedures.  Internet-Draft, (July 23, 1992).
  494.  
  495.           [4]  S. Kent, Privacy Enhancement for Internet Electronic
  496.                Mail -- Part II: Certificate-Based Key Management.
  497.                Internet-Draft, (August 6, 1992).
  498.  
  499.           [5]  D. Balenson, Privacy Enhancement for Internet Electronic
  500.                Mail -- Part III: Algorithms, Modes, and Identifiers.
  501.                Internet-Draft, (September 3, 1992).
  502.  
  503.           [6]  B. Kaliski, Privacy Enhancement for Internet Electronic
  504.                Mail -- Part IV: Key Certification and Related Services
  505.                Internet-Draft, (September 1, 1992).
  506.  
  507.  
  508.  
  509.  
  510.  
  511.  
  512.  
  513.  
  514.  
  515.  
  516.  
  517.  
  518.  
  519.  
  520.  
  521.  
  522.  
  523.           Expires May 16, 1993                                  [Page 9]
  524.  
  525.  
  526.  
  527.  
  528.  
  529.           draft                MIME-PEM Interaction               Jan 93
  530.  
  531.  
  532.           11.  Author Addresses
  533.  
  534.           Steve Crocker
  535.           Trusted Information Systems
  536.           email:  crocker@tis.com
  537.  
  538.           Ned Freed
  539.           Innosoft International, Inc.
  540.           250 West First Street, Suite 240
  541.           Claremont, CA 91711
  542.           USA
  543.           Tel:    +1 909 624 7907
  544.           Fax:    +1 909 621 5319
  545.           email:  ned@innosoft.com
  546.  
  547.           Marshall T. Rose
  548.           Dover Beach Consulting, Inc.
  549.           420 Whisman Court
  550.           Moutain View, CA  94043-2186
  551.           Tel:    +1 415 968 1052
  552.           Fax:    +1 415 968 2510
  553.           email:  mrose@dbc.mtview.ca.us
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562.  
  563.  
  564.  
  565.  
  566.  
  567.  
  568.  
  569.  
  570.  
  571.  
  572.  
  573.  
  574.  
  575.  
  576.  
  577.  
  578.  
  579.  
  580.  
  581.  
  582.           Expires May 16, 1993                                 [Page 10]
  583.  
  584.